The importance of being discovery-driven

Change is a constant around us. And without a doubt, the pace of change has exponentially accelerated with the help of technology and millisecond access to information anytime, anyplace. What does this mean for agile delivery? That discovery must be constant, as I explore in this blog post.

In a fast-changing and uncertain world, we need to stop assuming that we have all the answers. Arguing about being right or creating detailed five-year plans isn’t very useful when we know that change is certain. We need to focus on testing different decisions instead of trying to craft the optimal solution from the outset — in other words, we need to let discovery guide our decisions.

Testing and learning from discovery

Being discovery-driven helps us to test decisions by observing the world around us through different lenses. For example, you can begin by viewing a problem through an anthropologist’s lens to understand customer behaviours. You can then switch to an entrepreneurial mindset to start running experiments. In the same vein, you can also explore new markets and events outside of your industry, tapping into a fresh perspective to inspire new opportunities for both your business and your customers.

How we learn is also critical for being discovery-driven. Let’s consider two scenarios:

1. The product team time boxes discovery, followed by a long delivery phase.
2. The product team prioritises building a solution over conducting discovery activities.

In both cases, the team is missing some big opportunities. The takeaway is that we have to remember that people never stop finding new ways to complete jobs, and that we always have to find ways for our businesses and products to remain relevant.

At Tecknuovo, we like to rally around these three approaches to learning through discovery:

1. Learn together

It’s all about people. With the pace of change, it’s difficult to remain an expert. Instead, we should strive to become experts in the art of collaboration. Team members should debate and create across the infinite space of opportunity before moving to the solution space. Instead of self-imposed deadlines or feature expectations, try out “what have we learned?” sessions to manage progress and learning across your team.

2. Learn fast

Think big, start small, learn fast. That’s easier said than done, but time constraints can actually prove a great tool for injecting creativity into your discovery. You want to rely on shortcuts and simplification, and avoid decision fatigue at every cost. Furthermore, you want to manage your judgement and decision-making so that these don’t interfere with reality. Drawing the distinction between testing assumptions and ideas is critical for injecting speed into your execution.

3. Learn cheap

Like time, cost is another fundamental constraint that aids in discovery. It’s hard to stop talking about how failure is bad. It’s easy, by comparison, to make low-cost intelligent failures that are rich in learning. The rise of no-code/low code platforms is a boon to lowering costs, fuelling faster application creation, and letting non-technical people contribute to development. Simulations either in the physical or digital space can also drastically reduce costs — for example by letting you simulate a production line in virtual reality before you spend millions on building it.

Growth through discovery

But enough theory. Moving on to a real example.

At Tecknuovo, we’re evolving our internal operations to facilitate further growth. The aim is to roll out more automation and more cross-tool integration to fulfil more demand.

The way you get started on a project like this is critical because asking the wrong questions at the start can set you off on the wrong path.

For example, asking “which tool do we want?” has an underlying assumption that we will bypass discovery. “What does the MVP look like?” is too early to ask at the beginning, because you haven’t addressed assumptions at that point. In brief, predetermining an execution path is a suboptimal approach, plainly because you haven’t yet started the activities that might necessitate a change of direction at a later time.

We believe that the right kind of questions come from tackling your initiative with a product mindset. Because in our opinion, discovery and delivery have equal weight in taking you from idea to reality.

In that spirit, we started our journey towards accelerating automation and integration by asking “what is the desired outcome?” and following that up with a review of the as-is system. We applied our anthropologist’s lens at the start, taming the desire to let cognitive biases highjack our brains. In short, we operated with a lot of discipline. Once we had identified enough opportunities, we shortlisted the most suitable one based on its impact radius across our workstreams.

The selected opportunity led to a shortlist of assumptions — described as use cases — that we wanted to validate. In the spirit of Design Sprints and the “learn cheap” principle, we signed up for a trial version of a tool and created the desired use cases in the span of one week.

Rather than further learning about this tool (we like it!) we set it aside as we had learned enough. Our aim is to repeat the process with another tool, and the total number of tools we end up testing will depend on context. All this time we have been in discovery mode, and have not fully committed to anything yet.

The lesson here is that we should never stop championing a discovery-driven mindset, always keeping our eyes open for a better option if the need arises. We strive for better solutions, not the right single solution.

Good luck with your discoveries.

Juan writes more about continuous product discovery and delivery on his blog. To read more, click here or follow along on LinkedIn here.